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Date: Sun,  3 Feb 91 04:30:06 PST
From: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>
Reply-To: Packet-Radio@ucsd.edu
Subject: Packet-Radio Digest V91 #33
To: packet-radio@ucsd.edu
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Today's Topics:
                 HELP with compiling Xenix SysV NET.
                       PACKET->Internet Gateway
                       recommended NOS version?
                         Shareware on Packet

Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 3 Feb 91 01:44:31 GMT
From: munnari.oz.au!manuel!csc.canberra.edu.au!echo!skcm@uunet.uu.net  (Carl Makin)
Subject: HELP with compiling Xenix SysV NET.
To: packet-radio@ucsd.edu

Hi,
I got a copy of the System V version of Net from TOMCAT for the house
Xenix system here and am having a REAL problem compiling it.  The code seems 
to compile OK but before I actually get to compiling it the MAKE program
falls over screaming "out of memory". :-(

Now I'm reasonably new to Xenix/Unix and C but as far as I can see the
only solutions would be either to compile it manually (urk) or split the
makefile.

Has anyone else had this sort of problem?

The machine I'm trying to compile it on is a 12Mhz 80286 running SCO Xenix
2.2.3 in 2.5Mb of RAM and 105Mb of Hard disk.

(Hopefully in a couple of weeks we can borrow 8Mb of RAM for a couple of days
but I'm not sure that will help. :-( )

Carl.

------------------------------

Date: 2 Feb 91 20:43:50 GMT
From: zaphod.mps.ohio-state.edu!rpi!uupsi!uhasun!jbloom@tut.cis.ohio-state.edu  (Jon Bloom)
Subject: PACKET->Internet Gateway
To: packet-radio@ucsd.edu

In article <253@platypus.uofs.edu>, bill@platypus.uofs.edu (Bill Gunshannon) writes:
> 
> I have heard numerous times that because the remote station would be 
> controlling the transmitter and he is (possibly) a non-ham that this
> would be illegal.  Now lets look at this from a practical technical
> aspect.  
> 
> If I put up a 10M <-> 2M cross-band repeater, a TECH can come on 2M
> and initiate a contact on 10M.  This is not considered illegal although
> the TECH is initiating the contact.  I have heard that this is OK under
> the rules covering 3rd Party traffic cause the TECH isn't the control
> operator of the 10M station.  Well, I'm sorry, but that doesn't wash 
> either.  Cause then all the 10M contacts with G-land AND DL-land etc.
> are illegal cause we don;t have 3rd party agreements with them.  The 
> fact of the matter is that the TECH on 2M never has control of the
> signal generated on 10M and that is why the FCC allows it.  I think 

The reason this doesn't fall under the normal third-party rules is that
the FCC has made explicit exceptions in the case of repeaters.  While
third-party traffic normally requires a control operator to be
present at the control point (see 97.109), automatic control of a
repeater is explicitly allowed [see 97.205(d)].  In the case of the
cross-band repeater with an output on 10m, the Technician cannot be
the control operator.  Fortunately, since a repeater is allowed to
be under automatic control, no control operator is needed.  But if
the originating signal is not coming from an amateur station, as would
be the case with Internet-originated data, the station is not, by
definition, a repeater [see 97.3(a)(34)].  So the analogy between cross-
band repeaters and an Internet gateway is false.

> the time has come to look at possible INTERNET<->AMPR gateways the same
> way.  If it takes letters to the FCC to convince them then so be it.
> If I put up such a gateway, I am controling the emissions of the transmitter
> not the guy in Odessa, TX who sent a message to one of the hams on the
> local LAN.

But you are *not* controlling the content of the messages being transmitted
by your station.  No ham is controlling that, and therein lies the problem.
 
> As long as all other rules are abided by, I can't see where there is any
> kind of legal problem.  I don't see a lot of difference between this and 
> NTS traffic which is non-ham (Happy Birthday, Merry Christmas etc.) put is
> placed into the amateur system at one point by a ham.  Basicly the same
> should apply to gateways.  I would be considered the ham putting the traffic
> into the amateur system.  
> The potential gain would be great.  Hams would be able to exchange ideas
> and colaborate with hams and non-hams alike in their technological projects.

I completely agree with your last statement.  But there *is* a legal
difference between the gateway and the NTS example.  See below.

[...Internet legalities deleted]

> So, would someone out there care to show me the error of my ways??  :-)
> I'm not interested in "Well, it you just can't do it, so there."
> I want concrete evidence that shows that the arguments that apply to one
> type of technology (cross-band repeaters) can't be applied to a new
> technology.

At the risk of (once again) being accused of being a technology-bashing,
Luddite, ARRL old fart, let me try to (once again) explain how it is that
the existing rules unfortunately prohibit unattended Internet->AMPR
gateways.

97.109(e) allows packet stations operating above 50 MHz to pass third-
party traffic under automatic control, but "The retransmitted messages
must originate at a station that is being locally or remotely controlled."
Even worse, messages originated by non-hams (where the notion of a control
operator can't possibly be stretched to cover the originator) surely come
under the requirements of 97.115(b) which states in part:

(b) The third party may participate in stating the message where:
   (1) The control operator is present at the control point and is
       continuously *monitoring* and supervising the third party's
       participation.  [Emphasis mine.]

This means that, under the current rules, you have to monitor (read)
the data being sent by the Internet participant.  A bit difficult in
an IP gateway!

Once again... cross-band repeaters are repeaters and fall under the
repeater rules.  An Internet gateway is *not* a repeater and does
*not* fall under these rules.  The reason the repeater rules were
created in the first place was to provide relief from the third-
party rules when only relay of *amateur* signals was involved.  Trying
to interpret these rules in some way that would allow automatic relay
of nonamateur signals violates both the spirit and letter of the repeater
rules.  Sorry.

-- 
Jon Bloom, KE3Z                              | American Radio Relay League
Internet: jbloom@uhasun.hartford.edu         |
Snail:    225 Main St., Newington, CT 06111  | "I have no opinions."

------------------------------

Date: 2 Feb 91 21:17:02 GMT
From: modcomp!dan@uunet.uu.net  (Dan Grostick)
Subject: recommended NOS version?
To: packet-radio@ucsd.edu

Can anyone recommend their favorite NOS version and where to get
it from. I have access to uunet but not directly to internet - 
except via a ftp-request mechanism that requires internet address
and file names.

Thanks

-Dan

N4IXP

------------------------------

Date: 2 Feb 91 17:10:00 GMT
From: zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!wa4mei!ke4zv!gary@tut.cis.ohio-state.edu  (Gary Coffman)
Subject: Shareware on Packet
To: packet-radio@ucsd.edu

In article <1991Jan31.044034.21294@maverick.ksu.ksu.edu> steve@matt.ksu.ksu.edu (Steve Schallehn) writes:
>A question was posed to me by an amateur who is interested in getting
>into packet.  It seems he has a large collection of shareware on his
>land-line BBS and he was wondering if he could legally set up his
>BBS on packet and allow shareware downloads.  
>
>I know about the avoiding business in amateur radio, but does 
>shareware count?

Shareware authors ask for and expect money for their product just like
any other business. They're just freeloading their marketing dept off
on to the public access systems. While shareware is probably the most
often pirated software, it's still a commercial product. Therefore it
would certainly be illegal to distribute it over amateur radio. Think 
of shareware as digital pizzas. :-)

On the other hand, true freeware and public domain software are perfectly 
ok to send over amateur radio.

Gary KE4ZV 

------------------------------

End of Packet-Radio Digest
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